home *** CD-ROM | disk | FTP | other *** search
/ Chip 1998 September / CHIP Eylül 1998.iso / Slackwar / docs / mini / Remote-Boot < prev    next >
Text File  |  1997-08-11  |  68KB  |  1,527 lines
  1.   Linux Remote-Boot mini-HOWTO:      Configuring Remote-Boot Worksta¡
  2.   tions    with Red-Hat Linux, DOS, Windows 3.1 and Windows 95
  3.   Marc Vuilleumier Stⁿckelberg, Sandro Viale and David Clerc
  4.   v2.5, August 1997
  5.  
  6.   This document describes how to set up a very robust server-based con¡
  7.   figuration for a cluster of PCs, allowing each client to choose at
  8.   boot-time which operating system to run. The key of this configuration
  9.   is the TCP/IP bootprom, which let the user choose at boot time one of
  10.   several boot images. The most up-to-date version of this document,
  11.   with hypertext links to downloadable software and other related mate¡
  12.   rials, can be found at the address
  13.   http://cuiwww.unige.ch/info/pc/remote-boot/howto.html.  Linuxdoc-SGML,
  14.   DVI and postscript versions are available in the same directory.
  15.  
  16.   1.  What has changed...
  17.  
  18.   1.1.
  19.  
  20.   A lot of things:
  21.  
  22.   ╖  The Linux server-based configuration and documentation have been
  23.      completely redesigned. It is now based on RedHat Linux 4.1, updated
  24.      to the 2.0.30 kernel. Linux system setup and maintenance has been
  25.      much simplified.
  26.  
  27.   ╖  The Dos and Windows configurations have been completely redesigned,
  28.      using a "hard-disk based" approach. This makes the configuration
  29.      MUCH easier, fasten the boot process, reduces the network load, and
  30.      even allows for a server-based setup of Windows NT station
  31.      (although this is not described in this document).
  32.  
  33.   ╖  We now use a DHCP server, with standard DHCP/BOOTP extensions (RFC
  34.      2132).
  35.  
  36.   ╖  This configuration now works also with Samba, the free SMB server,
  37.      instead of a Novell server. In fact, we are now on the point of
  38.      throwing away of our Novell server...
  39.  
  40.   1.2.
  41.  
  42.   A new banner feature has been added to the bpunzip utility.  A bug in
  43.   MRZIP, which caused "Bad compressed data" errors during disk image
  44.   decompression, has been found and fixed.
  45.  
  46.   Several precisions were added to the documentation. Links to related
  47.   software (Shared LAN Cache) and documentation (from J. Carlstedt, of
  48.   The Cathedral School of Uppsala, Sweden) have also been added.
  49.  
  50.   2.  Introduction
  51.  
  52.   The configuration described here was developped since Summer 1996 at
  53.   the CUI, University of Geneva. The Computer Science Department uses
  54.   several servers (both Unix and Novell), and a number of PCs, which
  55.   fall into two classes:
  56.  
  57.   ╖  computers devoted to students
  58.  
  59.   ╖  computers devoted to research and teaching assistants
  60.  
  61.      We developped the current configuration with the following aims:
  62.  
  63.   ╖  Every computer should be able to run under Linux, DOS, Windows 3.1
  64.      or Windows 95. One should be able to choose the desired operating
  65.      system for each session.
  66.  
  67.   ╖  All softwares, including operating systems, should reside on the
  68.      server, in order to facilitate the installations and upgrades.
  69.  
  70.   ╖  Clients computers should be able to run without any write-access on
  71.      the server (for security reasons), except their home directory.
  72.  
  73.   ╖  Client-side configuration should be reduced to its very minimum.
  74.      Clients should automatically get their IP configuration parameters
  75.      from the server, and this information should be located in a single
  76.      file, used for all operating systems.
  77.  
  78.   ╖  Since almost every computer now has a hard-disk, clients should be
  79.      able to take profit of it for reducing network load and as
  80.      temporary storage space for the user.
  81.  
  82.   ╖  Users must have a login to be able to use any of the computers.
  83.  
  84.   ╖  The login should be the same for all operating system and should
  85.      let the user access its unique home directory, common to all
  86.      operating systems.
  87.  
  88.   ╖  Students computers should be fully cleaned up at each start. That
  89.      is, the PC should always look like if it were just installed.
  90.  
  91.   ╖  Every computer has to be protected from virus attacks.
  92.  
  93.      These constraints lead us to base our configuration on the
  94.      excellent TCP/IP Bootprom from K÷ppen EDV GmbH.  This bootprom is
  95.      especially interesting because it is not devoted to any specific
  96.      operating system; it just emulates a floppy disk, and can easily be
  97.      used for booting Linux as well as DOS or Windows 95.  Moreover, the
  98.      bootdisk image can be replaced by a home-made program, that let us
  99.      perform several initializations before the operating system itself
  100.      starts.
  101.  
  102.   2.1.  The Network
  103.  
  104.   The University of Geneva owns a class B domain, subdivided into
  105.   several subnets. The CUI uses four subnets, among them one is
  106.   dedicated to students.
  107.  
  108.   Originally, our PCs were concerned about two network protocols: IPX
  109.   and IP.  On the IPX side, we used a single Novell Netware 3 server for
  110.   sharing software and users files for DOS and Windows. On the IP side,
  111.   we used a SUN server for sharing software and users partitions for
  112.   Linux, with NFS.
  113.  
  114.   In our latest configuration, we do not any more use IPX. There is a
  115.   single Unix server (which could be Linux as well as a SUN), sharing
  116.   software and user files using NFS for Linux clients and using SMB
  117.   (NetBIOS) over TCP/IP for Dos and Windows clients.
  118.  
  119.   2.2.  How it Works
  120.  
  121.   1. When a client PC is turned on, it first performs the traditional
  122.      system checks before the TCP/IP bootprom takes the control.
  123.  
  124.   2. The bootprom issues a BOOTP/DHCP request in order to get its IP
  125.      configuration parameters.
  126.   3. If the server knows the PC issuing the request, it will send back a
  127.      BOOTP/DHCP reply with informations such as the client's IP address,
  128.      the default gateway, and which bootdisk image to use.  Otherwise,
  129.      the server will just discard the request.
  130.  
  131.   4. The bootprom then downloads the bootdisk image from the server
  132.      using the TFTP protocol, and emulates at the BIOS level a floppy
  133.      disk with this image.
  134.  
  135.   5. The PC boot on this disk image, which happens to contains a single
  136.      boot program (no operating system yet).
  137.  
  138.   6. If the PC is a student computer, the program starts by downloading
  139.      by TFTP a small text file containing the expected hard-disk
  140.      configuration for the computer. According to this file, the
  141.      partition table is rebuilt and DOS partitions are quick-formatted.
  142.      When all this is done, no more than three seconds have elapsed
  143.      since the computer was turned on.
  144.  
  145.   7. The program then offers to the user the choice of the operating
  146.      system for the session.
  147.  
  148.   8. According to the choice of the user, a new bootdisk image is
  149.      downloaded from the server, using TFTP.
  150.  
  151.   9. If the user decides to use Linux, the boot image is a a kernel
  152.      loader plus a compressed kernel, with support for NFS root and
  153.      caching filesystem:
  154.  
  155.      a. First, the IP configuration is made according to the BOOTP/DHCP
  156.         reply received from the Novell server.
  157.  
  158.      b. The kernel is then able to mount a read-only root filesystem,
  159.         using NFS.
  160.  
  161.      c. A small ramdisk is set up and mounted to the places where write
  162.         access is desirable.
  163.  
  164.      d. If a swap partition is found on the local hard disk, it is
  165.         prepared and activated.
  166.  
  167.      e. If a linux partition is found on the local hard disk, it is
  168.         mounted and prepared for caching NFS partitions.
  169.  
  170.      f. IP configuration is finalized, services are started, and xdm is
  171.         launched.
  172.  
  173.      g. The user is asked for its login. The workstation is ready.
  174.  
  175.   10.
  176.      If the user decides to use DOS or Windows, the boot image is a
  177.      program that handle compressed images of FAT16 partitions.  Images
  178.      are downloaded using TFTP, and stored for further use at the very
  179.      end of the hard-disk, above any used partition.  More precisely,
  180.      the program works in the following way:
  181.  
  182.      a. The program download a checksum file (512 bytes) that validates
  183.         the boot image of the choosen operating system
  184.  
  185.      b. If the wanted image is not present at the end of the disk, or if
  186.         the checksum does not match (because the image has been
  187.         corrupted or because a new release has been installed on the
  188.         server), the full image is transferred using TFTP.
  189.  
  190.      c. The operating system image is decompressed into the first FAT16
  191.         partition, at the approximate speed of one second per used
  192.         megabyte.
  193.  
  194.      d. The program jump into the boot sector of the selected OS, which
  195.         is now completely present on the local hard-disk.
  196.  
  197.      For DOS and Windows 3.1, we use the freely available Microsoft Lan¡
  198.      Manager for DOS (search the network for the mirror nearest to you;
  199.      the distribution consists of three files named disk1 to disk4) as
  200.      SMB client. Microsoft LanManager supports dynamic configuration
  201.      using DHCP. After logging in, the user is faced to DOS, and can
  202.      start Windows 3.1 by typing the traditional win command. Note that
  203.      at this point, DOS and Windows 3.1 appear to be installed locally.
  204.  
  205.      For Windows 95, we also use Microsoft SMB client (called Client for
  206.      the Microsoft Network), that supports dynamic configuration using
  207.      DHCP. We reduce network load using Shared LAN Cache, a nice and
  208.      powerful network-to-disk cache program.
  209.  
  210.      Students computers can be turned off the hard way at any time with¡
  211.      out risks, since the hard disk is reinitialized at each start.
  212.  
  213.   For "safe" computers (ie. for assistants computers), once the computer
  214.   has been booted once using the above described system, the boot image
  215.   can be changed to a simple program that redirect the boot to the local
  216.   hard-disk, without cleaning it again. This allow users to leave data
  217.   on their local hard disk. But whenever the configuration gets
  218.   corrupted, it is sufficient to change the boot image for one start in
  219.   order to get a fresh installation.
  220.  
  221.   2.3.  Related non-commercial documentations
  222.  
  223.   This configuration has been successfully reproduced at several places
  224.   around the world. A few people have written some hints and tricks that
  225.   complement this How-To. If you did so and that your page is not
  226.   already referenced in this documentation, please send an e-mail to
  227.   Marc.VuilleumierStuckelberg@cui.unige.ch.  And if you experience
  228.   problems while reproducing this configuration, have a look at these
  229.   pages !
  230.  
  231.   ╖  http://www.katedral.se/system/elevsyst, by Johan Carlstedt of The
  232.      Cathedral School of Uppsala, Sweden.
  233.  
  234.   3.  The Configuration How-To
  235.  
  236.   First, arrange to have the following two machines within arm's reach:
  237.  
  238.   ╖  the server, for us a Unix machine
  239.  
  240.   ╖  the client, a PC with a TCP/IP bootprom enabled, and nothing
  241.      valuable on the hard disk.
  242.  
  243.      If you want to test the configuration but you do not yet have a
  244.      TCP/IP Bootprom, you can download the demo diskette from
  245.      http://www.incom.de.  This diskette will make your computer behave
  246.      like if it had a TCP/IP Bootprom plugged in.
  247.  
  248.   For student computers, we configured our Bootprom for boot on network
  249.   first, and disabled hard-disk and floppy-disk boot. For assistant
  250.   computers, we also configured our Bootprom for network-boot, but we
  251.   allow hard-disk and floppy-disk boot; use this kind of Bootprom in
  252.   your setup client.
  253.  
  254.   On the server, setup a DHCP daemon (we use the official version from
  255.   the Internet Software Consortium, release 970329).  You also need to
  256.   enable a TFTP daemon. This document assume that you use the extended
  257.   TFTP daemon provided on your TCP/IP Bootprom Utility disk. If you
  258.   prefer to use a standard TFTP daemon, remove the P in all boot image
  259.   name extensions, in order to tell the Bootprom to use only the
  260.   standard TFTP port (see the TCP/IP Bootprom documentation).
  261.  
  262.   Don't forget that BOOTP/DHCP requests are bounded by subnets. If the
  263.   client and the server do not reside on the same subnet, you should
  264.   install a gateway on any computer between the two. For now, just
  265.   assume that both machines are on the same subnet.
  266.  
  267.   First, we will do everything common to all operating systems, ie:
  268.  
  269.   ╖  Configure the initial hard-disk setup and cleaning
  270.  
  271.   ╖  Configure the operating system choice menu
  272.  
  273.   ╖  Test the boot process
  274.  
  275.      Then, for each operating system, we will go through the following
  276.      steps:
  277.  
  278.   ╖  Setup a stand-alone client
  279.  
  280.   ╖  Save its configuration on the server
  281.  
  282.   ╖  Test it as a remote-boot client
  283.  
  284.   ╖  Adapt it so that it works for any similar client machine
  285.  
  286.      Once this is done, you will be able to setup any supplemental
  287.      client just by plugging a BootPROM in it and adding a few lines in
  288.      the DHCP configuration file.
  289.  
  290.   3.1.  Setting Up the Boot Process
  291.  
  292.   In the server /tftpboot directory, put the following special boot
  293.   images (warning for hypertext readers: these are binary files)
  294.  
  295.   ╖  bpclean, our hard-disk cleaning utility
  296.  
  297.   ╖  bpmenu, the TCP/IP Bootprom menu program (included with your
  298.      bootprom utility disk)
  299.  
  300.   ╖  bpunzip, our hard-disk restore utility
  301.  
  302.   ╖  bphdboot, the image that redirect the boot process to the hard disk
  303.  
  304.   3.1.1.  The Initial Hard-disk Setup and Cleaning
  305.  
  306.   In the same directory, create a symbolic link to (or make a copy of)
  307.   bpclean named XXXclean (or whatever you want that that can help you
  308.   remember that it is a clean-up image for your client machine) and
  309.   create a text file named XXXclean.tab describing what partition table
  310.   you want for your client, and what boot image you want to chain.  For
  311.   instance, for a 2 Gb hard-disk, we use
  312.  
  313.   ______________________________________________________________________
  314.   # Comments are allowed, but file should not exceed 512 bytes
  315.   # Hex numbers should be prefixed by $
  316.  
  317.   # Part |       |  Part
  318.   # type | Boot? |  Size
  319.      6      Y       +500 Mb
  320.     $82     N       +31 Mb
  321.     $83     N       -50 Mb
  322.      0
  323.  
  324.   # Bootimage to chain
  325.   /tftpboot/XXXmenu
  326.   ______________________________________________________________________
  327.  
  328.   The precise format of the file is described later in this document.
  329.   For now, all you need to know is that
  330.  
  331.   ╖  partition type 6 is BIGDOS, ie. DOS Fat-16 from 32Mb to 500Mb
  332.  
  333.   ╖  partition type hex 82 is Linux Swap
  334.  
  335.   ╖  partition type hex 83 is Linux Ext2fs
  336.  
  337.   ╖  the negative size means that we partition three should occupy all
  338.      available space but 50 Mb
  339.  
  340.   ╖  partition type 0 means empty (unused) partition entry.
  341.  
  342.      For now, bpclean will not erase the content of any partition but
  343.      rewrite the master boot record, including the partition table.
  344.  
  345.   3.1.2.  The Operating System Choice Menu
  346.  
  347.   Similarly, create a symbolic link to (or make a copy of) bpmenu named
  348.   XXXmenu (or whatever you want that that can help you remember that it
  349.   is a boot menu image for your client machine) and create a text file
  350.   named XXXmenu.m containing the boot menu for your machine. You might
  351.   either create this file by hand, or use our menuedit.exe full-screen
  352.   menu editor. For the example, assume that you use the following file:
  353.  
  354.        ______________________________________________________________________
  355.        ______________________________________________________________________
  356.  
  357.   3.1.3.  Testing the Boot Process
  358.  
  359.   Create an entry in the DHCP configuration file for your client.  Set
  360.   the boot image to /tftpboot/XXXclean.  You will probably need to
  361.   restart the DHCP server to take your changes into account.
  362.  
  363.   Now, start your client. You should quickly see messages from bpclean,
  364.   telling you the size of the partitions created, and then the boot menu
  365.   should appear on your screen. You can use the pause key on the
  366.   keyboard just before the menu is loaded in order to be able to read
  367.   the messages, but it will probably time-out the TFTP connection.
  368.  
  369.   If you press the key 1, you should get a message saying that the boot
  370.   partition contains not valid boot sector.  This is normal since the
  371.   boot partition has not been formatted.  Any other keys should fail
  372.   since we did not make any boot image for now...
  373.  
  374.   We will now install the various operating systems.  You can do that in
  375.   what order you want.  For each OS, you will initially need to start it
  376.   from a boot floppy.  In order to do that, just press the space bar at
  377.   the very beginning of the boot process, just after the TCP/IP Bootprom
  378.   banner.
  379.  
  380.   Some operating system might change the master boot record. In
  381.   particular, the Linux kernel loader (lilo) does that.  Such changes
  382.   would be destroyed by bpclean, so you should better change the DHCP
  383.   entry for your client so that the boot image is directly
  384.   /tftpboot/XXXmenu (no clean).  Don't forget to restart the DHCP server
  385.   to take your changes into account.
  386.  
  387.   3.2.  Setting Up Linux
  388.  
  389.   Set up RedHat Linux 4.1 on your client, with network support, kernel
  390.   sources and any packages you may want.  Prepare future moint points (a
  391.   /mnt/tmp will be usefull), setup your X server, and so on.  In the
  392.   directory /usr/src/linux-2.0.27, you should have the source code for
  393.   the kernel 2.0.27.
  394.  
  395.   We will now apply some patches, in order to upgrade to 2.0.30, and to
  396.   support the TCP/IP Bootprom and the filecache.  The filecache is the
  397.   mechanism by which you can reduce network loading by saving "on-the-
  398.   fly" NFS files on your local hard disk.  TCP/IP Bootprom support has
  399.   been written by Marc Vuilleumier Stuckelberg, and ported to kernel 2.0
  400.   by David Clerc. The filecache has been written by Unifix GmbH, and is
  401.   part of Unifix Linux 2.0. Both TCP/IP Bootprom support and the
  402.   filecache have been made freely distributable by their authors.
  403.  
  404.   Note that Linux NFS-Root support is still based on BOOTP, not DHCP.
  405.   But since DHCP is just an extension of BOOTP, Linux will work as well
  406.   with a DHCP server (if you did not configure your DHCP server to deny
  407.   BOOTP requests).
  408.  
  409.   3.2.1.  Building the Kernel
  410.  
  411.   First, go to your /usr/src directory and apply the following patches,
  412.   using the command
  413.  
  414.   patch -p0 < the-patch-file:
  415.  
  416.   ╖  patch-2.0.28: this is the official kernel update, a big patch that
  417.      you should better apply
  418.  
  419.   ╖  patch-config-sound: a cosmetic patch for the sound configuration,
  420.      taken from Unifix Linux 2.0
  421.  
  422.   ╖  patch-PCSP: a rather big patch for adding soundcard emulation using
  423.      the PC speaker, taken from Unifix Linux 2.0
  424.  
  425.   ╖  patch-bootprom: a small patch that will let you produce a special
  426.      kernel image, usable as a boot image with the TCP/IP Bootprom
  427.  
  428.   ╖  patch-filecache: a small patch that adds special functionalities to
  429.      your kernel, so that you can use Unifix filecache. Taken from
  430.      Unifix Linux 2.0
  431.  
  432.   ╖  patch-penguinlogo: a small patch that will help your end-users to
  433.      wait until your Linux system is completely loaded
  434.  
  435.   ╖  patch-2.0.29: another official kernel update patch, much smaller.
  436.      You do not need to apply this patch if you don't want to have the
  437.      latest kernel release.
  438.  
  439.   ╖  patch-2.0.30: yet another official kernel update patch, quite big.
  440.      Again, you do not need to apply this patch (but it improves
  441.      TCP/IP). If you do not have sources for the alpha on your machine
  442.      (which is most probable), this patch will complain twice about an
  443.      include file that does not exist. Do not worry, just answer that
  444.      you want to skip the missing file and everything will be okay.
  445.  
  446.      Then run make mrproper and make xconfig, to customize the contents
  447.      of your kernel.  Remember that this will be the only software the
  448.      client computer will be given for starting Linux, so it must
  449.      contains everything necessary to launch the whole operating system.
  450.      Modules should be used, but not for networking support since the
  451.      network is needed to load the kernel modules. In brief, your kernel
  452.      should contains at least
  453.  
  454.   ╖  networking support
  455.  
  456.   ╖  NFS-Root support, with BOOTP support
  457.  
  458.   ╖  filecache support
  459.  
  460.   ╖  support for the client computer hardware, possibly modular
  461.  
  462.      You may use our .config as a starting point. Ensure that you have
  463.      included support for your hard disk directly in the kernel if you
  464.      want to be able to test it without the bootprom.
  465.  
  466.   When you are done with your choices, type the usual make clean; make
  467.   dep and then make zImage, make modules and make modules_install. This
  468.   will take a while...  You are now ready to test your new kernel, first
  469.   using lilo.  Install your kernel (see lilo documentation), and reboot
  470.   your computer (from the local hard disk).  If there are any errors,
  471.   fix them and try again.  Run depmod -a to compute the modules
  472.   dependencies.  When there are no more errors, do a make bpImage to
  473.   build a bootimage for use with the TCP/IP Bootprom.
  474.  
  475.   3.2.2.  Moving the Root Filesystem to NFS
  476.  
  477.   Have enough place on your server to hold the whole content of your
  478.   Linux filesystem (some hundred Megabytes).  Create a new directory for
  479.   NFS export, named rootfs, and create another new directory within it
  480.   named runtime.  We use /export/linux/rootfs/runtime. Export it read-
  481.   write, with root access (annon=0), for your Linux client only. For
  482.   instance, our NFS server is running under Solaris, and we gave the
  483.   command:
  484.  
  485.   share -F nfs -o rw=pc7971,anon=0 /export/linux/rootfs/runtime.
  486.  
  487.   Mount this partition on your Linux client and copy the whole Linux
  488.   system on it using GNU tar (the default on RedHat Linux).  It is
  489.   important that you use GNU tar because all tar might not be able to
  490.   handle correctly special nodes such as block devices.  Then edit the
  491.   /export/linux/rootfs/runtime/etc/fstab file and change the entry for
  492.   the root directory so that it corresponds to an nfs mount instead of a
  493.   local hard disk. You also need to remove (or at least rename)
  494.   /export/linux/rootfs/runtime/etc/sysconfig/network-scripts/ifcfg-eth0
  495.   since the network device will be initialized by NFS-root and should
  496.   not be initialized twice.
  497.   Now duplicate the linux entry in your /etc/lilo.conf, using the name
  498.   linux-nfs for instance, and add the following parameter to it:
  499.  
  500.   append="root=/dev/nfs nfsroot=/export/linux/rootfs/runtime
  501.   nfsaddrs=your-ip:server-ip:gateway-ip:netmask:machine-name"
  502.  
  503.   (where your-ip is the decimal dotted notation for your Linux client IP
  504.   address, server-ip is the NFS server IP address, gateway-ip is the
  505.   default gateway used by the Linux machine, netmask is the netmask and
  506.   machine-name is the hostname of the Linux machine).  Run lilo again,
  507.   reboot your computer (still from the hard disk), and choose linux-nfs
  508.   boot settings. Your computer should behave almost as before, although
  509.   probably slower. If something doesn't work at this point, you can
  510.   simply reboot with your local linux boot configuration and try to fix
  511.   it. Most probably, you made the NFS root settings wrong.  If there is
  512.   something you don't understand, have a look at the
  513.   /usr/src/linux/Documentation files...  You might also look at the NFS-
  514.   Root-Mini-Howto.
  515.  
  516.   You can repeat the experience with only append="root=/dev/nfs" to
  517.   ensure that the Linux kernel is able to get your IP parameters using a
  518.   DHCP/BOOTP request. For this to work, you should have the following
  519.   options in your DHCP configuration file (set with your own values, of
  520.   course), in addition to your machine hardware and IP addresses:
  521.  
  522.        ______________________________________________________________________
  523.        option subnet-mask 255.255.252.0;
  524.        option routers 129.194.68.1;
  525.        option root-path "/export/linux/rootfs";
  526.        ______________________________________________________________________
  527.  
  528.   If your Linux kernel needs additional command-line parameters, you can
  529.   add them using option option-177.
  530.  
  531.   The next step is to have our system work with a read-only NFS
  532.   filesystem.
  533.  
  534.   3.2.3.  Building the Read-only NFS Root Filesystem
  535.  
  536.   Since we want our root filesystem to be mounted read-only by regular
  537.   linux clients, we have to make a slightly different filesystem, so
  538.   that we can put a ramdisk or a filecache on places where write access
  539.   is desirable.  We will build this filesystem in the
  540.   /export/linux/rootfs directory, so that the standard distribution is
  541.   directly available under /runtime/.  Log on your NFS server and create
  542.   the following directories and links, under /export/linux/rootfs:
  543.  
  544.   ╖  bin -> cache/bin
  545.  
  546.   ╖  dev -> ramdisk/dev
  547.  
  548.   ╖  etc -> ramdisk/etc
  549.  
  550.   ╖  lib -> cache/lib
  551.  
  552.   ╖  root -> ramdisk/root
  553.  
  554.   ╖  sbin -> cache/sbin
  555.  
  556.   ╖  tmp -> ramdisk/tmp
  557.  
  558.   ╖  usr -> cache/usr
  559.  
  560.   ╖  var -> ramdisk/var
  561.  
  562.   ╖  cache/
  563.  
  564.   ╖  bin -> /runtime/bin
  565.  
  566.   ╖  lib -> /runtime/lib
  567.  
  568.   ╖  sbin -> /runtime/sbin
  569.  
  570.   ╖  usr -> /runtime/usr
  571.  
  572.   ╖  mnt/
  573.  
  574.   ╖  cdrom/
  575.  
  576.   ╖  floppy/
  577.  
  578.   ╖  tmp/
  579.  
  580.   ╖  proc/
  581.  
  582.   ╖  ramdisk/
  583.  
  584.   ╖  dev -> /runtime/dev
  585.  
  586.   ╖  etc -> /runtime/etc
  587.  
  588.   ╖  root -> /runtime/root
  589.  
  590.   ╖  tmp -> /runtime/tmp
  591.  
  592.   ╖  var -> /runtime/var
  593.  
  594.      As you can see, it looks like a regular root filesystem, except
  595.      that some entries are redirected to a ramdisk, while some other are
  596.      redirected to the cache directory.  When booting on a read-only NFS
  597.      filesystem, we will mount an initialized ramdisk on /ramdisk.
  598.      Similarly, a local hard disk partition will be mounted on /cache
  599.      for caching NFS requests.  Roughly, the principle of the filecache
  600.      is that whenever a symbolic link from the cache subdirectory is
  601.      followed, it is replaced by its target. If the target is itself a
  602.      subdirectory, each entry of the subdirectory becomes a symbolic
  603.      link to the original entry of the foreign filesystem. Note that it
  604.      is necessary for the filecache to use absolute symbolic links, even
  605.      if they are meaningless on the NFS server. If you don't like that,
  606.      create a symbolic link from /runtime to
  607.      /export/linux/rootfs/runtime on your NFS server.
  608.  
  609.   It is then necessary to add some setup stuff to the read-only client,
  610.   in order to mount the ramdisk, to setup the filecache and to detect
  611.   hardware in order to customize the configuration files.  This is done
  612.   by three scripts and one configuration file, that you should copy to
  613.   your NFS server:
  614.  
  615.   ╖  runtime/etc/rc.d/rc.ramdisk, which quickly setup and mount the
  616.      ramdisk:
  617.  
  618.   ______________________________________________________________________
  619.   #!/bin/sh
  620.   #
  621.   # Setup a ramdisk because root was mounted read-only by NFS
  622.   #
  623.   modprobe rd
  624.   gzip -c -d /runtime/lib/ramdisk.gz | dd of=/dev/ram bs=1k > /dev/null 2>&1
  625.   mount -n -t ext2 /dev/ram /ramdisk
  626.   ______________________________________________________________________
  627.  
  628.   ╖  runtime/etc/rc.d/rc.sysdetect, which does all machine-dependant
  629.      configuration, including detecting and preparing local hard disk
  630.      partitions for the filecache. It is not included in the printed
  631.      version of this document for space reasons, but can be found in the
  632.      hypertext version;
  633.  
  634.   ╖  runtime/etc/rc.d/init.d/filecache.init which starts the filecache
  635.      itself:
  636.  
  637.        ______________________________________________________________________
  638.        #!/bin/sh
  639.        #
  640.        # filecache:    Starts the filecache (for NFS root)
  641.        #
  642.  
  643.        # Source function library.
  644.        \&. /etc/rc.d/init.d/functions
  645.  
  646.        # See how we were called.
  647.        case "$1" in
  648.          start)
  649.                if [ -e /cache -a -r /etc/filecache.conf ]; then
  650.                        echo -n "Starting NFS filecache: "
  651.                        # move var and tmp to the local hard drive
  652.                        rm -rf /cache/var /cache/tmp
  653.                        (cd /ramdisk; tar cf - var tmp) | (cd /cache; tar xf -)
  654.                        (cd /ramdisk; rm -rf var tmp;ln -s /cache/var;ln -s /cache/tmp
  655.        )
  656.                        chmod 777 /cache/tmp
  657.                        # start cache
  658.                        daemon filecache -d on
  659.                        echo ""
  660.                        touch /var/lock/subsys/filecache
  661.                fi
  662.                ;;
  663.          stop)
  664.                filecache off
  665.                rm -f /var/lock/subsys/filecache
  666.                ;;
  667.          *)
  668.                echo "*** Usage: filecache.init {start|stop}"
  669.                exit 1
  670.        esac
  671.  
  672.        exit 0
  673.        ______________________________________________________________________
  674.  
  675.   ╖  runtime/etc/filecache.conf, the filecache configuration file
  676.  
  677.   ______________________________________________________________________
  678.   Max 100 MB 50 % #
  679.   Cache /runtime /cache
  680.   ______________________________________________________________________
  681.  
  682.   The first two files should be invoked at the beginning of run¡
  683.   time/etc/rc.d/rc.sysinit, as follow:
  684.  
  685.        ______________________________________________________________________
  686.        # Setup ramdisk if necessary (for read-only root NFS)
  687.        if [ -e /ramdisk -a -r /etc/rc.d/rc.ramdisk ]; then
  688.                /etc/rc.d/rc.ramdisk
  689.        fi
  690.  
  691.        # Setup hardware dependent parameters (for any root NFS)
  692.        if [ -r /etc/rc.d/rc.sysdetect ]; then
  693.                /etc/rc.d/rc.sysdetect
  694.        fi
  695.        ______________________________________________________________________
  696.  
  697.   and the third one should be bound as usual to the System V init direc¡
  698.   tories: we use links named S35filecache in the rc3.d and rc5.d direc¡
  699.   tories, and K80filecache in the rc0.d, rc1.d, rc2.d and rc6.d directo¡
  700.   ries.
  701.  
  702.   Take a look at the rc.sysdetect file, and adapt it to your hardware.
  703.   In particular, if you do not use the same video adapters and screen as
  704.   we do (which is very likely :-), see how they report to /proc/pci and
  705.   modify the script according to that.  There is a section of
  706.   rc.sysdetect with customize configuration files (for instance the
  707.   printcap), according to the machine location. For this to work, you
  708.   need to set each machine location using the special tag option-132 of
  709.   the server dhcpd.conf file.  Before you continue this installation,
  710.   you must at least build basic runtime/etc/fstab.ref and
  711.   runtime/etc/hosts.ref files, which will be finalized by the
  712.   rc.sysdetect script on boot time, according to the detected
  713.   configuration.  For dynamically configuring the X server, there is one
  714.   thing you have to change from the RedHat distribution: in the
  715.   /usr/X11R6/bin and /usr/X11R6/lib/X11 directories, there are a few
  716.   relative links to configuration files and directories that should be
  717.   changed to absolute links. Don't forget to do that again if you
  718.   reinstall later an upgrade of the X server.
  719.  
  720.   Install the filecache in runtime/bin, and its man page in
  721.   runtime/usr/man/man8.  Install bootptag in runtime/usr/local/bin, and
  722.   bootptag.c in runtime/usr/local/src: it is a simple program that
  723.   issues a BOOTP request and answer its content on the standard output,
  724.   in a shell-compatible format, as in the following example:
  725.  
  726.   ______________________________________________________________________
  727.   bootp_your_ip='129.194.71.32'
  728.   bootp_server_ip='129.194.77.31'
  729.   bootp_filename='XXXclean'
  730.   bootp_subnet_mask='255.255.252.0'
  731.   bootp_routers='129.194.68.1'
  732.   bootp_domain_name_servers='129.194.69.200 129.194.8.7 129.194.4.32'
  733.   bootp_host_name='pc7132'
  734.   bootp_domain_name='unige.ch'
  735.   bootp_root_path='/export/linux/rootfs'
  736.   bootp_broadcast_address='129.194.71.255'
  737.   bootp_nis_domain='cuisunnet.unige.ch'
  738.   bootp_nis_servers='129.194.69.200'
  739.   bootp_option_132='dufour'
  740.   ______________________________________________________________________
  741.  
  742.   The name of the tags is similar to that used in the dhcpd configura¡
  743.   tion file. We use this program for auto-configuration in rc.sysdetect.
  744.   Finally, install the makeramdisk script in runtime/lib. We will use it
  745.   to build automatically the ramdisk image. All these software are
  746.   available in the hypertext version of this document.
  747.  
  748.   Now try to boot your read-write NFS client (still boot from the hard
  749.   disk).  It should detect your local configuration, and generate the
  750.   appropriate files. Check that /etc/fstab, /etc/hosts,
  751.   /etc/sysconfig/network have been created correctly. If it is not the
  752.   case, retry in single user mode, and debug the rc.sysdetect script to
  753.   discover what you have done wrong.
  754.  
  755.   When it works, go to the /lib directory and run ./makeramdisk.  This
  756.   will take a few seconds, and build a ramdisk image for the read-only
  757.   NFS clients. Install the created ramdisk image under /lib/ramdisk.gz,
  758.   and your configuration is ready !
  759.  
  760.   3.2.4.  Booting from the Bootprom
  761.  
  762.   If you did not already do it, install your TCP/IP Bootprom-compliant
  763.   kernel image (found in /usr/src/linux/arch/i386/boot/bpImage) as
  764.   /tftpboot/linux.PX on your server.  The rc.sysdetect script is able to
  765.   initialize for you the Linux swap and a Linux data partition. In order
  766.   to trigger it, edit the XXXclean.tab file on the server and change the
  767.   partitions types from hex 82 to hex 28, and from hex 83 to hex 38.
  768.   This is not a known partition type, but it will be recognized by the
  769.   setup script as partitions to prepare.  In the DHCP configuration
  770.   file, set the boot file to XXXclean again, in order to rebuild the
  771.   partition table.  Do not forget to restart the DHCP daemon after you
  772.   changed the configuration file.
  773.  
  774.   Finally, unexport the read-write runtime directory, and export read-
  775.   only the /export/linux/rootfs directory. Restart the client, and this
  776.   time boot using the Linux menu option.  Your system will now remote-
  777.   boot Linux.
  778.  
  779.   3.2.5.  System Maintenance and Upgrades
  780.  
  781.   If you want later to upgrade software, install bug fixes and security
  782.   fixes, proceed as follow:
  783.  
  784.   ╖  Unexport the rootfs directory
  785.  
  786.   ╖  Export the runtime directory read-write for your client
  787.  
  788.   ╖  Set your client nfsroot directory to runtime (in the /etc/bootptab)
  789.  
  790.   ╖  Start your Linux client, and install everything you want.  Do not
  791.      be afraid of using rpm, it works perfectly well (just be carefull
  792.      when you install packages that might alter modifications that you
  793.      have made yourself).
  794.  
  795.   ╖  Redo the normal export when you are done
  796.  
  797.      That means, you can upgrade software on your server-based
  798.      configuration as if it were a local install.
  799.  
  800.   3.3.  Setting up DOS 6 and Windows 3.1
  801.  
  802.   On the client computer, boot on your favorite dos floppy disk
  803.   (remember, abort the BootPROM by pressing space during boot).  Format
  804.   the dos partition of your hard-drive with the /S option, in order to
  805.   put the operating system on it.  Create a DOS subdirectory, copy DOS
  806.   in it. Install your favorite network client (for instance Microsoft
  807.   LanManager), Windows 3.1, and so on. Use DHCP for the IP
  808.   configuration.
  809.  
  810.   You should recover the memory used by the BootPROM (since it is not
  811.   any more needed when the DOS starts) by inserting the following line
  812.   at the beginning of your config.sys:
  813.  
  814.        ______________________________________________________________________
  815.        device=\util\bputil.sys -r
  816.        ______________________________________________________________________
  817.  
  818.   (bputil is a program provided on the TCP/IP Bootprom utility disk).
  819.   Do not be afraid to use EMM386 to optimize the memory usage, and even
  820.   to include the area where you put your network adapter ROM, since it
  821.   is not used anymore at this time. But carefully exclude the network
  822.   adapter RAM, or you will not be able to connect to your server.
  823.  
  824.   If you want to ensure that the client machine cannot be used without a
  825.   valid login name, include our nobreak.sys pseudo-device driver at the
  826.   beginning of your config.sys and put something like this in your
  827.   autoexec.bat:
  828.  
  829.        ______________________________________________________________________
  830.        rem -- we use the dummy file c:\logged as a flag
  831.        del c:\logged >nul
  832.        :loginneeded
  833.        cls
  834.        echo Please type in your login name and password
  835.        echo.
  836.        net logon *
  837.        rem -- the login script should have created c:\logged
  838.        if not exist c:\logged goto loginneeded
  839.        del c:\logged
  840.        rem -- now enable break again
  841.        echo Yes >NOBRK
  842.        ______________________________________________________________________
  843.  
  844.   Ensure that your client boot well by rebooting and choosing the Boot
  845.   from local hard-disk option in the boot menu.
  846.  
  847.   3.3.1.  Moving the Configuration to the Server
  848.  
  849.   On the server, make a share called admin for instance, on which you
  850.   will put some stuff for the system administrator.  If the server is a
  851.   Unix machine, it is a good opportunity to put in admin a softlink to
  852.   the /tftpboot subdirectory, so that you can put images in it directly
  853.   from the client.  Within admin, create a /utils subdirectory and put
  854.   the following utilities in it:
  855.  
  856.   ╖  mrzip.exe, a program that will create a compressed image of your
  857.      hard disk.
  858.  
  859.   ╖  mrunzip.exe, a program that can restore from within DOS a
  860.      compressed image of your hard disk.
  861.  
  862.      You might also like to put in the same directory a simple batch
  863.      file that does some clean-up and then create the compressed image,
  864.      like this one:
  865.  
  866.        ______________________________________________________________________
  867.        @echo off
  868.        if "%1"=="" goto error
  869.        echo >c:\lanman.dos\lmuser.ini
  870.        l:\utils\mrzip l:\tftpboot\%1
  871.        goto end
  872.        :error
  873.        echo Usage: MAKEIMG {image-name-without-extension}
  874.        :end
  875.        ______________________________________________________________________
  876.  
  877.   Now go back to your client, mount the admin volume on drive L: for
  878.   instance and execute either your batch file if you have created one,
  879.   or the following command (absolute path names are not required, but
  880.   they do not hurt :-)
  881.  
  882.        ______________________________________________________________________
  883.                L:\util\mrzip L:\tftpboot\win31
  884.        ______________________________________________________________________
  885.  
  886.   One minute later, you will have two new files in your server /tftpboot
  887.   subdirectory, namely win31.imz, the compressed image of your hard disk
  888.   and win31.chk, the associated checksum file (which is in fact a
  889.   slightly modified copy of the partition boot record).  In this very
  890.   directory, just create a symbolic link to (or a copy of) bpunzip named
  891.   win31.P.
  892.  
  893.   Your disk-based remote-boot configuration is now ready.
  894.  
  895.   3.3.2.  Testing the Remote-Boot Client
  896.  
  897.   Now reboot your client and choose the DOS and Windows 3.1 option of
  898.   the boot menu. The bpunzip program shall give you some message about
  899.   his creating an image table, and then download the whole boot image
  900.   from the network (since it is the first time that it sees this boot
  901.   image). This will take about one minute.  Then it will uncompress the
  902.   image to the DOS partition, and boot it. Here you are, your remote-
  903.   boot client is ready !  Next time you reboot it, it will only
  904.   uncompress the image, probably in less than 30 seconds.
  905.  
  906.   3.3.3.  Adapting the configuration for other Machines
  907.  
  908.   If you want to customize some settings according to the machine, to
  909.   its location (such as the default printer), or if you need to make
  910.   some changes in your network configuration files that cannot be
  911.   handled through DHCP, you can use the unzipreg.exe program from within
  912.   the client autoexec.bat.  This program will read a special hidden file
  913.   created by bpunzip, namely BOOTP.ANS, that contains the original
  914.   BOOTP/DHCP reply sent by the server. Then, it will read the file given
  915.   as first argument, substitute all strings of the form
  916.   UNZIPREG:tagname: by their content in the BOOTP/DHCP reply and write
  917.   the result on the file given as second argument. For instance, if you
  918.   have a file named input.bat which contains:
  919.  
  920.        ______________________________________________________________________
  921.        set domainname=UNZIPREG:DOMAINNAME:
  922.        set printer=UNZIPREG:T180:
  923.        ______________________________________________________________________
  924.  
  925.   and you execute the command
  926.  
  927.        ______________________________________________________________________
  928.                unzipreg input.bat output.bat
  929.        ______________________________________________________________________
  930.  
  931.   you will get a file output.bat containing:
  932.  
  933.        ______________________________________________________________________
  934.        set domainname=unige.ch
  935.        set printer=laserwriter1
  936.        ______________________________________________________________________
  937.  
  938.   assuming that your DHCP configuration file defines the domain name as
  939.   unige.ch and the option-180 tag as laserwriter1.
  940.  
  941.   Note that it is also possible to customize the Windows desktop
  942.   according to the login. We wrote a simple program to add a group to
  943.   the PROGMAN.INI file, allowing to customize the desktop for each group
  944.   of users.
  945.  
  946.   After making any change to the client machine configuration, do not
  947.   forget to rebuild the disk image using mrzip if you want to preserve
  948.   your changes.
  949.  
  950.   3.4.  Setting up Windows 95
  951.  
  952.   In previous versions of this document, we used the Microsoft server-
  953.   based installation of Windows 95, but it was really too much pain and
  954.   not much worth:
  955.  
  956.   ╖  It is very, very bogus
  957.  
  958.   ╖  Many software package do not support it and their install will
  959.      fail.  Among them, Microsoft Internet Explorer, OnNet 32, Novell's
  960.      Protected-mode client (which is MUCH more secure than Microsoft
  961.      Client for Netware).
  962.  
  963.   ╖  It cannot be used with the Microsoft Network client over TCP/IP,
  964.      since Microsoft provides no real-mode driver for TCP/IP compatibe
  965.      with Windows 95. That means, it cannot be used with Samba
  966.  
  967.   ╖  It makes software upgrades almost impossible since every client
  968.      turned on will lock many DLLs on the server, and thus produce
  969.      sharing violations if you try to upgrade them.
  970.  
  971.      Consequently, we throwed away of this document all the informations
  972.      and bug-workaround collected during months (you can still find them
  973.      as a HTML document at http://cuiwww.unige.ch/info/pc/remote-
  974.      boot/win95old/win95old.html) and turned to our new disk-based
  975.      remote-boot concept.  Basically, the configuration for Windows 95
  976.      is now almost as easy the configuration for DOS.
  977.  
  978.   3.4.1.  Setting up a Stand-Alone Client
  979.  
  980.   Boot the client computer in DOS, either using the Boot menu if you
  981.   have already setup the DOS/Windows 3.1 configuration, or using a
  982.   floppy disk (aborting the BootPROM by pressing space).  The advantage
  983.   of the first solution is that you will then have a running network
  984.   client, and that you probably already have somewhere on your server
  985.   the distribution disks for Windows 95.
  986.  
  987.   If you boot from a floppy disk, you will probably first need to format
  988.   the dos partition of your hard-drive with the /S option, in order to
  989.   put the operating system on it.  If you boot using a DOS/Windows 3.1
  990.   configuration start by removing files that you don't need for Windows
  991.   95 setup and that you do not want to be in your final boot image (for
  992.   instance, the WINDOWS directory).
  993.  
  994.   Start Windows 95 setup, and follow all steps of a local install.  At
  995.   the end of the install, setup will reboot your computer, make some
  996.   settings and reboot again. For all these reboot, choose the Boot from
  997.   local hard-disk option of your boot menu.  Once you have set up all
  998.   drivers you want, you shall consider running defrag and doing a full
  999.   defragmentation (including defragmenting free space).
  1000.  
  1001.   You should also consider recovering the memory used by the BootPROM by
  1002.   inserting the following line at the beginning of your config.sys:
  1003.  
  1004.        ______________________________________________________________________
  1005.        device=\util\bputil.sys -r
  1006.        ______________________________________________________________________
  1007.  
  1008.   (bputil is a program provided on the TCP/IP Bootprom utility disk).
  1009.   In opposition to DOS, you shall better avoid to use EMM386 with Win¡
  1010.   dows 95.
  1011.   If you want to reduce network and server load (which will improve your
  1012.   system performances) while keeping all softwares on the server, you
  1013.   should consider installing the excellent Shared LAN Cache, from
  1014.   Measurement Techniques, Inc (see http://www.lancache.com).  This
  1015.   software runs on each client computer, and caches to the local hard
  1016.   disk every data obtained from the network. Even MS-Office starts much
  1017.   faster the second time you run it... You need one license per client
  1018.   computer, but it is not very expensive, and the firm make special
  1019.   prices for universities and colleges. The best thing to do is to go to
  1020.   their Web site and download the free evaluation copy.
  1021.  
  1022.   3.4.2.  Moving the Configuration to the Server
  1023.  
  1024.   On the server, if you don't already have it, make a share called admin
  1025.   for instance, on which you will put some stuff for the system
  1026.   administrator.  If the server is a Unix machine, it is a good
  1027.   opportunity to put in admin a softlink to the /tftpboot subdirectory,
  1028.   so that you can put images in it directly from the client.  Within
  1029.   admin, create a /utils subdirectory and put the following utilities in
  1030.   it:
  1031.  
  1032.   ╖  mrzip.exe, a program that will create a compressed image of your
  1033.      hard disk.
  1034.  
  1035.   ╖  mrunzip.exe, a program that can restore from within DOS a
  1036.      compressed image of your hard disk.
  1037.  
  1038.   Open a MS-DOS window on your client, mount the admin volume on drive
  1039.   L: for instance and execute the following command (absolute path names
  1040.   are not required, but they do not hurt :-)
  1041.  
  1042.        ______________________________________________________________________
  1043.                L:\util\mrzip L:\tftpboot\win95
  1044.        ______________________________________________________________________
  1045.  
  1046.   This will create two new files in the /tftpboot subdirectory of your
  1047.   server, namely win95.imz, the compressed image of your hard disk and
  1048.   win95.chk, the associated checksum file (which is in fact a slightly
  1049.   modified copy of the partition boot record).  In this very directory,
  1050.   just create a symbolic link to (or a copy of) bpunzip named win95.P.
  1051.  
  1052.   Your disk-based remote-boot configuration of Windows 95 is now ready.
  1053.  
  1054.   3.4.3.  Testing the Remote-Boot Client
  1055.  
  1056.   Now reboot your client and choose the Windows 95 option of the boot
  1057.   menu. The bpunzip program shall give you some message about his
  1058.   updating the image table, and then download the whole boot image from
  1059.   the network (since it is the first time that it sees this boot image).
  1060.   This will take about two minutes.  Then it will uncompress the image
  1061.   to the DOS partition, and boot it. Here you are, your remote-boot
  1062.   client is ready !  Next time you reboot it, it will only uncompress
  1063.   the image, probably in about 40 seconds.
  1064.  
  1065.   3.4.4.  Adapting the configuration for other Machines
  1066.  
  1067.   The big difference between Windows 3.1 and Windows 95 is that the
  1068.   later includes code for Plug-and-play , ie. automatic detection of
  1069.   your hardware. This not a bad thing in itself, but the trouble is that
  1070.   it is often too sensible, and that it sometimes fails.
  1071.  
  1072.   If you try to start another client with exactly the same boot image,
  1073.   you will probably get several messages during startup telling that
  1074.   Windows has detected new hardware: a new sound card, a new hard-disk,
  1075.   a new network card, and even a new mouse... There can be two reasons
  1076.   for that:
  1077.  
  1078.   ╖  the devices may not use the same ressources (for instance the mouse
  1079.      is not connected on the same port, or the sound card is not
  1080.      connected in the same slot - yes, that is detected)
  1081.  
  1082.   ╖  the devices may tell to Windows 95 their personal serial number
  1083.      (for instance, every Windows 95 differenciate every network card on
  1084.      the basis of its world-wide unique ethernet address)
  1085.  
  1086.      The fact that Windows 95 discover that the hardware has changed may
  1087.      not be a problem if the plug-and-play works as-is, but it become a
  1088.      problem when the plug-and-play does not work. For instance, Windows
  1089.      95 plug-and-play for our Logitech PS2/aux mouse does not work, and
  1090.      result in no mouse at all. To solve such kind of problems, arrange
  1091.      to have all computers as similar as possible.
  1092.  
  1093.   The thing you cannot avoid to differ between computers is the network
  1094.   card. Bad luck for us, the plug-and-play code for our SMC EtherEZ card
  1095.   hangs the computer. The only solution is to let Windows 95 believe
  1096.   that it already know the network card, and that it is not necessary to
  1097.   trigger plug-and-play. The trick for doing that is to automatically
  1098.   insert an entry for the network card in Windows 95 registery, from the
  1099.   autoexec.bat.  Note that this trick is not any more needed with most
  1100.   PCI cards.
  1101.  
  1102.   On your client computer, edit the autoexec.bat and add the following
  1103.   lines:
  1104.  
  1105.        ______________________________________________________________________
  1106.        rem --- Patch Windows registery in order to avoid plug-and-play detection
  1107.        cls
  1108.        unzipreg c:\lib\smc.reg c:\temp\smc.reg
  1109.        regedit /L:c:\win95\system.dat /R:c:\win95\user.dat c:\temp\smc.reg
  1110.        echo.
  1111.        del c:\temp\smc.reg
  1112.        ______________________________________________________________________
  1113.  
  1114.   regedit is a standard Windows 95 program that let you browse the reg¡
  1115.   istery if you start it from within Windows 95, or do simple operations
  1116.   on the registery if you call it from DOS.  unzipreg.exe is a small
  1117.   home-made program that you should put somewhere in your path.  It will
  1118.   read a special hidden file created by bpunzip, namely BOOTP.ANS, that
  1119.   contains the original BOOTP/DHCP reply sent by the server. Then, it
  1120.   will read the file given as first argument, substitute all strings of
  1121.   the form UNZIPREG:tagname: by their content in the BOOTP/DHCP reply
  1122.   and write the result on the file given as second argument.
  1123.  
  1124.   In in the lib subdirectory, we have a file named smc.reg with the
  1125.   following content:
  1126.  
  1127.   ______________________________________________________________________
  1128.   REGEDIT4
  1129.  
  1130.   [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C0]
  1131.   "HardwareID"="*SMC8416,ISAPNP\SMC8416"
  1132.   "HWRevision"="1.0.10"
  1133.   "DeviceDesc"="SMC EtherEZ (8416)"
  1134.   "Class"="Net"
  1135.   "Driver"="Net\\0001"
  1136.   "CompatibleIDs"="*SMC8416"
  1137.   "Mfg"="SMC"
  1138.   "ConfigFlags"=hex:10,00,00,00
  1139.  
  1140.   [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C0\Bindings]
  1141.   "MSTCP\\0001"=""
  1142.  
  1143.   [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C0\LogConfig]
  1144.   "0000"=hex:00,04,00,00,00,20,00,00,10,00,00,00,04,00,00,00,00,00,00,00,a8,0e,\
  1145.     00,00,20,00,00,00,02,00,00,00,01,00,0c,00,00,00,00,00,00,00,00,00,e0,ff,20,\
  1146.     00,40,02,ff,03,00,00,04,03,2c,00,00,00,01,00,00,00,01,00,14,00,00,00,00,00,\
  1147.     00,00,00,00,00,00,00,00,00,e0,ff,ff,00,20,00,00,00,00,0c,00,ff,ff,0f,00,00,\
  1148.     00,00,00,2c,00,00,00,01,80,00,00,01,00,14,00,00,00,00,00,00,00,00,00,00,00,\
  1149.     00,00,00,e0,ff,ff,00,80,00,00,00,00,0c,00,ff,5f,10,00,00,00,00,00,00,00,00,\
  1150.     00
  1151.  
  1152.   [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C1]
  1153.   "HardwareID"="*SMC8416,ISAPNP\SMC8416"
  1154.   "HWRevision"="1.0.10"
  1155.   "DeviceDesc"="SMC EtherEZ (8416)"
  1156.   "Class"="Net"
  1157.   "Driver"="Net\\0001"
  1158.   "CompatibleIDs"="*SMC8416"
  1159.   "Mfg"="SMC"
  1160.   "ConfigFlags"=hex:10,00,00,00
  1161.  
  1162.   [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C1\Bindings]
  1163.   "MSTCP\\0001"=""
  1164.  
  1165.   [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C1\LogConfig]
  1166.   "0000"=hex:00,04,00,00,00,20,00,00,10,00,00,00,04,00,00,00,00,00,00,00,a8,0e,\
  1167.     00,00,20,00,00,00,02,00,00,00,01,00,0c,00,00,00,00,00,00,00,00,00,e0,ff,20,\
  1168.     00,40,02,ff,03,00,00,04,03,2c,00,00,00,01,00,00,00,01,00,14,00,00,00,00,00,\
  1169.     00,00,00,00,00,00,00,00,00,e0,ff,ff,00,20,00,00,00,00,0c,00,ff,ff,0f,00,00,\
  1170.     00,00,00,2c,00,00,00,01,80,00,00,01,00,14,00,00,00,00,00,00,00,00,00,00,00,\
  1171.     00,00,00,e0,ff,ff,00,80,00,00,00,00,0c,00,ff,5f,10,00,00,00,00,00,00,00,00,\
  1172.     00
  1173.   ______________________________________________________________________
  1174.  
  1175.   This file was initially generated using the Windows 95 interface to
  1176.   regedit. We exported the branch corresponding to our network adapter
  1177.   (HKEY_LOCAL_MACHINE/Enum/ISAPNP/SMC8416) and substituted the number
  1178.   corresponding to the adapter hardware address by the tag
  1179.   UNZIPREG:MACID:. When we run unzipreg on this file, it will automati¡
  1180.   cally substitute the tag by the number corresponding to the actual
  1181.   netword adapter. Note that there is one number after the MACID that
  1182.   was sometimes C0, sometimes C1. Since it does not hurt to put a non-
  1183.   existant adapter in the registery, we add entries for both.
  1184.  
  1185.   Once again, this whole trick is not necessary when using PCI network
  1186.   adapters.  Incidentally, we can use the same mechanism for
  1187.   automatically configuring the hostname, which Windows 95 does not seem
  1188.   to take into account when configuring through DHCP. We just add the
  1189.   following line to our smc.reg file:
  1190.        ______________________________________________________________________
  1191.        [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETSUP]
  1192.        "ComputerName"="UNZIPREG:HOSTNAME:"
  1193.  
  1194.        [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
  1195.        "HostName"="UNZIPREG:HOSTNAME:"
  1196.  
  1197.        [HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\ComputerName\ComputerName]
  1198.        "ComputerName"="UNZIPREG:HOSTNAME:"
  1199.        ______________________________________________________________________
  1200.  
  1201.   You can also use the same mechanism to customize other settings
  1202.   according to the machine type or to its location. For examples of
  1203.   that, see also the corresponding paragraph of the DOS/Windows 3.1
  1204.   configuration description.
  1205.  
  1206.   After making any change to the client machine configuration, do not
  1207.   forget to rebuild the disk image using mrzip, or all your changes will
  1208.   be lost.
  1209.  
  1210.   Using this small registery trick, your configuration should normally
  1211.   be portable for all machines with similar configurations. If you
  1212.   cannot avoid that Windows detect some hardware as new on one machine,
  1213.   try to rebuild the disk image from this machine. This will include the
  1214.   registery configuration specific to this machine into the image, and
  1215.   hopefully supress the problem.
  1216.  
  1217.   As the disk image decompression may take some time (typically 20-30
  1218.   sec.), you may want to give to the user informations or just a nice
  1219.   picture to look at.  This can be done very easily (see the
  1220.   documentation on BPUNZIP below).
  1221.  
  1222.   If you are interested in getting more informations and tools for
  1223.   configuring Samba with remote boot computers, we have written another
  1224.   document. Have a look at http://cuiwww.unige.ch/info/pc.
  1225.  
  1226.   4.  TCP/IP Bootprom Related Utilities
  1227.  
  1228.   This section gives some informations on the use of the utilities we
  1229.   wrote for use with the TCP/IP Bootprom.
  1230.  
  1231.   4.1.  MENUEDIT
  1232.  
  1233.   This is a program running under DOS, for editing menu scripts usable
  1234.   with the TCP/IP Bootprom. It is very basic, but is still much more
  1235.   comfortable to use than the menu scripts themselves. You can get
  1236.   online-help by depressing the F1 key. If you want to enhance it (for
  1237.   instancing adding cut-and-paste), I would be happy to publish your new
  1238.   version.
  1239.  
  1240.   Pascal source code is available here.
  1241.  
  1242.   4.2.  BPHDBOOT
  1243.  
  1244.   This boot image will load the hard-disk master boot record and jump
  1245.   into it.
  1246.  
  1247.   This boot image is particularly convenient to use when configuring an
  1248.   operating system that wants you to reboot before it finalizes its
  1249.   configuration. It can also be used on computers for which you do not
  1250.   want to impose a hard-disk cleanup at any time but you still want to
  1251.   be able to do it whenever needed.
  1252.  
  1253.   Assembler source code is available here.
  1254.  
  1255.   4.3.  BPCLEAN
  1256.  
  1257.   This boot image rewrite the hard-disk master boot record, including
  1258.   the hard-disk partition table. Moreover, it can quick-format a DOS
  1259.   (FAT16) data partition (but cannot make it bootable).  For copyright
  1260.   reasons, we had to program our own master boot record and FAT16 boot
  1261.   sector. They should behave more or less like the standard
  1262.   implementation, except that some messages have been adapted for the
  1263.   context of remote-boot computers. In order to have this program work,
  1264.   you might need to disable the BIOS master boot record protection
  1265.   (which is anyway not any more necessary since it will be refreshed at
  1266.   each boot).
  1267.  
  1268.   This program downloads the partition table description file with the
  1269.   same basename as itself and the .tab extension. This file can contains
  1270.   empty lines, comments beginning with a sharp but should never exceed
  1271.   512 characters.
  1272.  
  1273.   The first four non-blank non-commented lines should contain the
  1274.   discription for the four hard disk partitions. The fifth non-blank
  1275.   non-commented line should contain the name of the next boot image to
  1276.   load.
  1277.  
  1278.   Partition description lines are made of several space- or tab-
  1279.   separated fields, and must be in one of the following three forms:
  1280.  
  1281.        ______________________________________________________________________
  1282.        type  boot?  1st-cyl  1st-head  1st-sect  last-cyl  last-head  last-sect
  1283.        type  boot?  1st-cyl  1st-head  1st-sect  relative-size
  1284.        type  boot?  relative-size
  1285.        ______________________________________________________________________
  1286.  
  1287.   ╖  In the first form, the file give the precise geometry of the
  1288.      partition.
  1289.  
  1290.   ╖  In the second form, the first sector position is given but the end
  1291.      of the partition is automatically calculated on the basis of the
  1292.      requested partition size.
  1293.  
  1294.   ╖  In the third form, the first sector is automatically deduced from
  1295.      the end of the previous partition and the end of the partition is
  1296.      automatically calculated on the basis of the requested partition
  1297.      size. This form is totally independant of the hard-disk geometry.
  1298.  
  1299.      Every number is assumed to be in decimal form, except when prefixed
  1300.      with a dollard, in which case it is assumed to be an hexadecimal
  1301.      number.
  1302.  
  1303.   ╖  The type of a partition is 4 for DOS partitions under 32Mb, and 6
  1304.      for DOS partitions from 32Mb to 500Mb.  Many other values can be
  1305.      found using Linux fdisk help for instance.
  1306.  
  1307.   ╖  The boot? field should be Y for the boot partition and N for all
  1308.      other partitions. This flag is used by the master boot record.
  1309.  
  1310.   ╖  The 1st-cyl, 1st-head and 1st-sect are the absolute coordinates of
  1311.      the first sector of the partition. Do not forget that while
  1312.      cylinders and heads are numbered starting from 0, sectors are
  1313.      numbered starting from 1.
  1314.  
  1315.   ╖  The last-cyl, last-head and last-sect are the absolute coordinates
  1316.      of the last sector of the partition. Partition usually end on a
  1317.      cylinder boundary.
  1318.  
  1319.   ╖  The relative-size of a partition takes can be expressed in the
  1320.      following ways:
  1321.  
  1322.   ╖  + 10 Mb which means that the partition should be at least 10 Mb
  1323.      (ie. 2048 sectors) big;
  1324.  
  1325.   ╖  - 100 Mb which means that the partition should leave at least 100
  1326.      Mb (ie. 20480 sectors) free for the next partitions;
  1327.  
  1328.   ╖  + 30 % which means that the partition should occupy at least 30
  1329.      percent of the space available at this point;
  1330.  
  1331.   ╖  - 70 % which means that the partition shouls leave at least 70
  1332.      percent of the space available at this point for the next
  1333.      partitions.
  1334.  
  1335.      Partitions defined by their relative size always end on a cylinder
  1336.      boundary, and unless the first sector position is precised, start
  1337.      after a head boundary. To our knowledge, this is conform to the
  1338.      standard usage.
  1339.  
  1340.   Whenever a label is appended at the end of a partition description
  1341.   line, the corresponding partition is formatted as a DOS FAT16
  1342.   partition, whatever its type. This is compatible both with partition
  1343.   types 4 and 6, and is particularely usefull for cleaning a DOS
  1344.   partition on a student computer for instance. Such quick-format only
  1345.   takes some tenths of a second.
  1346.  
  1347.   By default, bpclean is compiled with support for LBA (no more than
  1348.   1024 cylinders, and up to 256 heads). Some strange BIOSes and some
  1349.   strange OSes prefer the so-called NORMAL mode (up to 4096 cylinders,
  1350.   but no more than 64 heads); if you need it, comment the LBA definition
  1351.   in the source code and recompile it.
  1352.  
  1353.   Assembler source code is available here.
  1354.  
  1355.   4.4.  MRZIP, MRUNZIP and BPUNZIP
  1356.  
  1357.   MrZip is a DOS program that can build a compressed raw image of a DOS
  1358.   FAT16 partition. It first analyses the disk usage in order to process
  1359.   only used data bytes, and then uses a very fast (but not very
  1360.   efficient) statistical compression algorithm to compress the data.
  1361.   Windows 95 long filenames are supported, and files with the .SWP
  1362.   extension are not saved. Several magic numbers are included between
  1363.   the various parts of the archive, and a checksum is computed on the
  1364.   original data. The checksum is stored as the low-order word of the
  1365.   volume serial number in the archive, while the high-order word is
  1366.   simply incremented.  If you zero the serial number of your hard-disk
  1367.   before building the compressed image, you can then use this number to
  1368.   track the number of updates to your image.
  1369.  
  1370.   Since MrZip uses direct disk access, it recommended that you flush any
  1371.   disk write cache before you run it. Windows 95 seems to handle direct
  1372.   disk access consistently.
  1373.  
  1374.   MrUnzip is a DOS program that can expand a compressed disk image to
  1375.   the hard-disk, using direct disk access. Do not use it in conjunction
  1376.   with any cache program, as it is already sufficiently afflicting for
  1377.   the DOS itself... Anyway, it can be very helpfull if you you want to
  1378.   fix a boot image that cannot boot anymore for instance.
  1379.  
  1380.   BpUnzip is a boot image that manage compressed hard disk images.
  1381.   Roughly, it will boot from the hard disk image with the same base
  1382.   name, with the extension .imz.
  1383.  
  1384.   It first read the partition table and look for
  1385.  
  1386.   ╖  the first DOS partition, where the disk image should be restored
  1387.  
  1388.   ╖  the last cylinder allocated for a partition, after which the
  1389.      compressed hard disk images will be stored.
  1390.  
  1391.      It then read the first sector of the first unused cylinder and see
  1392.      if there is already an image table. If it is not the case, or if
  1393.      the image table contains some inconsistency, or if both shift keys
  1394.      are depressed (a special general-cleaning signal), the image table
  1395.      is cleared.
  1396.  
  1397.   If the image table does not already contains the requested image, it
  1398.   is loaded using TFTP and added to the image table. If there is not
  1399.   enough space after previously loaded images for the new one, old
  1400.   images are discarded. If the image was already present in the image
  1401.   table, the most recent image boot sector (including the checksum) is
  1402.   loaded by TFTP and compared against the available image. If they are
  1403.   not exactly the same, the compressed image is reloaded.
  1404.  
  1405.   The image is then uncompressed, all magic numbers are verified, and
  1406.   the checksum is computed on the decompressed data. If the
  1407.   decompression fails, or if the checksum does not match the value
  1408.   included in the most recent boot sector, the image is assumed to be
  1409.   corrupted and is reloaded. Otherwise, the program gives the control to
  1410.   the boot sector, and the operating system is started.
  1411.  
  1412.   If bpunzip was loaded with a .P extension (for instance as win95.P),
  1413.   it is assumed that the TFTP server has an extended interface on port
  1414.   59 (in addition to the regular interface on port 69).  BpUnzip will
  1415.   then use it for loading the image using bigger packets, typically 1408
  1416.   bytes instead of 512 bytes per packet (this convention for using
  1417.   triggering the use of big packets is very similar to that used by the
  1418.   TCP/IP Bootprom).
  1419.  
  1420.   Similarly, if bpunzip was loaded with a .G extension (for instance as
  1421.   win95.GP), it will first download a GIF file with the same basename
  1422.   (for instance win95.gif) and display it on the screen during the whole
  1423.   operation. The program works only in 800x600, 256 color mode (although
  1424.   the GIF file can be smaller and use less colors). If your video
  1425.   adapter is not VESA compatible, this feature is not available to you.
  1426.   Note than the last 16 colors of the palette are used to display the
  1427.   progress bar banner. Either do not use them, or expect them to be
  1428.   incorrect. By the way, if you don't like our progress bar banner, feel
  1429.   free to change it (in GIFDATA.ASM), but please leave our names visible
  1430.   somewhere.
  1431.  
  1432.   The target partition does not have to be exactly of the same size as
  1433.   the original one; it just have to be big enough to hold the clusters
  1434.   from the beginning of the partition to the last used cluster.  If the
  1435.   destination partition is smaller than the original partition, the FAT
  1436.   will be shrinked accordingly (but not the cluster size).  If the the
  1437.   destination partition is bigger than the original partition, the FAT
  1438.   will be expanded as much as possible. However, if the destination
  1439.   partition is much bigger than the original, it is likely that 65518
  1440.   clusters will not be enough to cover all space (since the cluster size
  1441.   cannot be adapted). In this case, bpunzip will issue a warning telling
  1442.   that some space is lost.
  1443.  
  1444.   By default, bpunzip is compiled with support for LBA (no more than
  1445.   1024 cylinders, and up to 256 heads). Some strange BIOSes and some
  1446.   strange OSes prefer the so-called NORMAL mode (up to 4096 cylinders,
  1447.   but no more than 64 heads); if you need it, comment the LBA definition
  1448.   in the source code and recompile it.
  1449.  
  1450.   Assembler source code is available here.
  1451.  
  1452.   You might encounter problems with Solaris 2.5 TFTP server when dealing
  1453.   with images bigger than 16 Megabytes. This is because it cannot handle
  1454.   more than 32768 packets per file.  This is a known bug, for which SUN
  1455.   currently provides no fix.  We suggest using the more efficient
  1456.   extended TFTP server (also provided for other OS on your TCP/IP
  1457.   Bootprom utility disk).
  1458.  
  1459.   4.5.  NOBREAK
  1460.  
  1461.   Nobreak.sys is a very small (about 350 bytes only) driver that you
  1462.   include at the beginning of your config.sys. Its goal is to secure the
  1463.   boot process, until the user is logged in.  DOS provides a setting for
  1464.   this (namely BREAK=OFF), but it is not drastic enough, and has almost
  1465.   no effect in the autoexec.bat.  Our driver works by modifying the
  1466.   scan-code of the key pressed when a break is requested, directly at
  1467.   the BIOS level.  This way, no program at all can receive a break until
  1468.   break is enabled again.
  1469.  
  1470.   The driver must be loaded from the config.sys (or using the devlod
  1471.   program from Undocumented DOS). Afterwards, break can be enabled by
  1472.   sending Yes to the NOBRK pseudo-device, and disabled again by sending
  1473.   No (in fact, only the first character, Y or N is significant).
  1474.  
  1475.   As this driver relies on the BIOS, it does only work for DOS and
  1476.   Windows 3.1.  Windows 95 has its own low-level keyboard handling
  1477.   routines.
  1478.  
  1479.   Assembler source code is available here.
  1480.  
  1481.   5.  Discussion
  1482.  
  1483.   We here discuss some theoretical issues related to our configuration.
  1484.  
  1485.   5.1.  Bootproms and Hard Disks
  1486.  
  1487.   Bootproms exist for quite a long time, but they are usually used for
  1488.   diskless computers only. In our opinion, bootproms are even more
  1489.   interesting for computers which have a local harddisk, since they
  1490.   allow to take profit of both sides:
  1491.  
  1492.   ╖  A bootprom make the configurations more robust, since it ensure
  1493.      that the computer will always boot the same way, no matter any
  1494.      virus or partition table crash. It can be used, as we did, to
  1495.      cleanup the harddisk even before the operating system is loaded.
  1496.  
  1497.   ╖  A local harddisk make the configuration more efficient, since it
  1498.      can reduce the network trafic through caching, and allows for
  1499.      efficient swap.
  1500.  
  1501.   5.2.  Which Bootprom ?
  1502.  
  1503.   Several bootproms are available for PCs. We had several reason for
  1504.   choosing the TCP/IP Bootprom from K÷ppen EDV GmbH:
  1505.  
  1506.   ╖  It is based on the BOOTP/DHCP protocol, which is publicly defined
  1507.      by RFCs.  The definition states that when a BOOTP/DHCP server
  1508.      receives a request from a client that he doesn't know, the server
  1509.      will not answer.  This avoids interferences between multiple
  1510.      servers, as you might sadly experience with the MSD boot server.
  1511.      Moreover, since IP broadcasts are confined to the local subnet,
  1512.      they produce less noise than their IPX counterpart.
  1513.  
  1514.   ╖  It is not bound to a specific operating system.
  1515.  
  1516.   ╖  Technical informations and API informations are available on
  1517.      request.
  1518.  
  1519.   ╖  Home-made boot loader can be written (as we have done)
  1520.  
  1521.   ╖  The boot process can be parametrized on many ways. Specifically, it
  1522.      allowed us to forestall floppy boot on old-fashioned AST computers,
  1523.      which BIOS did not include this feature.
  1524.  
  1525.   ╖  Tools are provided for building and maintaining boot menus.
  1526.  
  1527.